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Scope 



The scope of the present document is to define the system requirements for reconfiguring the radios in mobile devices. 
The work will be based on the Use Cases defined in TR 103 062 [i.l], TR 102 839 [i.2] and TR 102 944 [i.3]. 



References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
reference document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http ://docbox . etsi . or g/Ref erence . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 
Not applicable. 

2.2 Informative references 

The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

[i.l] ETSI TR 103 062: "Reconfigurable Radio Systems (RRS); Use Cases and Scenarios for Software 

Defined Radio (SDR) Reference Architecture for Mobile Device". 

[i.2] ETSI TR 102 839: "Reconfigurable Radio Systems (RRS); Multiradio Interface for Software 

Defined Radio (SDR) Mobile Device Architecture and Services". 

[i.3] ETSI TR 102 944: "Reconfigurable Radio Systems (RRS); Use Cases for Baseband Interfaces for 

Unified Radio Applications of Mobile Device". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

resource: resource that radio application needs in active state, which includes processor and accelerator loads, memory 
usage, interconnect bandwidth occupation. Radio Frequency (RF) circuitry, etc. 

NOTE: Resources are provided by the reconfigurable Mobile Device (MD), to be used by the radio applications 
when they are active. Radio applications provide their resource needs (e.g. using operational states) so 
that the multiradio computer may judge whether these resources are available, in order to ensure 
non-conflicting operation with other radio applications. Resources may or may not be shared in the MD. 
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3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

ASIC Application Specific Integrated Circuit 

BBI BaseBand Interface 

BER Bit Error Rate 

BPA Baseband Parameter Aggregation 

CAT Category 

CII Context Information Interface 

CR Cognitive Radio 

DoA Direction of Arrival 

EEC Eorward Error Correction 

EET East Eourier Transform 

IP Internet Protocol 

IR Intermediate Representation 

MAC Media Access Control 

MD Mobile Device 

MDRC Mobile Device Reconfiguration Classes 

MIMO Multi-Input Multi-Output 

MU-MIMO Multi User-MIMO 

PER Packet Error Rate 

PMI Precoding Matrix Indicator 

RAI Radio Application Interface 

RAT Radio Access Technology 

RE Radio Frequency 

RI Rank Indicator 

RPI Radio Programming Interface 

RRS Reconfigurable Radio Systems 

RSSI Received Signal Strength Indication 

Rx Recieve 

SDR Software Defined Radio 

SINR Signal to Interference-plus-Noise Ratio 

SU-MIMO Single User-MIMO 

Tx Transmit 

URA Unified Radio Application 



4 Requirement Organization and Methodology 

This clause is containing the description of how the requirements are organised and the format of the requirement. 



4.1 Requirement Organization 



The present document is structured such that a level 1 section is dedicated to the requirements associated with a single 
category. The requirements should be partitioned into groups of related category to assist understanding. The overall 
structure is shown in figure 4.1.1. 
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Functional 

Requirements 

Category 

Requirements on 
RAT T.ink Support 
and Management 



Rase Band Interface 
Requirements 



Base Band Funetion 
Block Requirt;mt;nLfe 



r 



Mobile Deviee 

Reconfig uraLion 

Requirements 



Figure 4.1.1: Overall requirememts structure 



4.2 Requirement Format 



A letter code system is defined which makes a unique identification of each requirement R-<CAT>-<GROUP>-<XX>. It 
should be constructed as follows: 

• R-: Standard requirement prefix 

• <CAT> 



Code 


Category 


FUNG 


Functional aspects 



• <GROUP>: Requirement group identifier. A letter code will be used for this identifier. The three first letters 
will give the identifier of the group. 

• <XX>: Requirement identifier within requirement group; range 01 => 99. 
EXAMPLE: R-FUNC-QOS-01 

4.3 Requirement Formulation 

A requirement formulation is defined which makes a unique way to formulate it. It will be built as follows: 
Title: <Title Description> 

• Description: <The description of the requirement shall be formulated using one of the following terms. As 
described into the ETSI Terms & Definitions database (TEDDI) , the terms are explained here for information: 

"shall" term means that the definition is an absolute requirement of a profile (shall equals is required to). 

"should" term means that among several possibilities one is recommended, in a profile, as particularly 
suitable, without mentioning or excluding others, or that a certain course of action is preferred but not 
necessarily required (should equals is recommended that). 
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"may" term means that a course of action is permissible within a profile (may equals is permitted to). 



5 Working assumptions 

5.1 Assumptions 

5.1 .1 Mobile Device Reconfiguration Classes 

As introduced in [i.2], clause 5.4: Radio computer deployment scenarios, it is expected that the reconfiguration 
capabilities of MD will evolve over time. The requirements defined in the present document will thus be introduced for 
the concerned Mobile Device Reconfiguration Classes (MDRC) as shown in figure 5.1.1.1. Figure 5.1.1.1 illustrates 
MDRC classified according to type of resource requirements and form of radio application package. 



No recoufiguratiou 


MDRC-0 


No resource share 
(fixed hardware) 


MDKC-1 


Pre-defmed static 
resources 


TvIDRC-2 


MDRC-5 


Static resource 
requirements 


^IDRC-3 


MDRC-6 


Dynamic resource 
requiremeuts 


IvIDRC-4 


MDRC-7 ^^ 




Platform-sp e cifi c 
executable code 


Platform- 

iiidependeiit source 

code or TR 



Figure 5.1.1.1: Definition of MDRCs according to reconfiguration capabilities 

Reconfiguration capability, which is determined by the type of resource requirements and the form of radio application 
package, is explained for each class as follows: 

1) MDRC-0: No MD reconfiguration is possible 

MDRC-0 represents legacy radio implementations and do not allow for MD reconfiguration (except for bug 
fixing and release-updates through firmware updates) or exploitation of Cognitive Radio (CR) features. 
MDRC-0 represents legacy radio implementations and do not allow for MD reconfiguration. 

2) MDRC-1 : Radio applications use different fixed resources 

In this scenario, at least some of the radios are implemented with non-software defined radio (SDR) 
technology, e.g. with dedicated Application Specific Integrated Circuits (ASICs), and are resource-wise 
independent of each other. Simple CR functionality may be supported through radio parameter management to 
the extent which the radio implementations allow. 
MDRC-1 implements multiple radio applications with fixed resources allocation and no resource sharing. 

The rule for resource allocation for multiple applications {Aj, A2, . . ., A^} can be formulated as follows: A- -^ 

/?•, V/g{ 1, ..., A^}, where /?• denotes resource allocated for application A- and 7?- n 7?- = for V/ i^j. Note that 
applications can be run concurrently in any combination; resource allocation mechanism within separate 
application is not specified. 
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3) MDRC-2: Radio applications use pre-defined static resources 

MDRC-2 implements multiple radio applications but no dynamic resource management is available. The radio 
applications for MDRC-2 come from a single radio application package which is normally provided by a MD 
vendor or SDR chipset manufacturer. In this scenario, we assume that software radio components in the radio 
application package are provided in platform- specific executable code. 

The rule for resource allocation for multiple applications {Aj, A2, . . ., A^} can be formulated as follows: A- -^ 

/?•, V/g{ 1, ...,N}, where 7?- denotes resource allocated for application A-, if 3ii^j so that 7?- nRji^0 then 

such applications cannot be run concurrently, all other combinations are allowed; resource allocation 
mechanism within separate application is not specified. 

4) MDRC-3: Radio applications have static resource requirements 

For MDRC-3, a resource budget is defined for each radio application. This budget contains a static resource 
measure that represents the worst-case resource usage of the application, generated at radio application 
compile-time. If an application is being started, the resource manager installed in MD of MDRC-3 checks its 
resource budget and the sum of all resource budgets of already running applications, and admits the new 
application only if the resources can still be guaranteed for all running applications. In this scenario, we 
assume that software radio components in the radio application package are provided in platform- specific 
executable code. 
The rule for resource allocation for multiple applications {Aj, A2, . . ., A^} can be formulated as follows: 

A • -^ R(A •), where R denotes total resources to be shared and R(A •) denotes a part of R allocated for A •; if for 

/7, /2, ..., iM g{ 1, ..., N},M<N, R(A -y) u R(A -2) u ... u R(A •^) e R then applications A -y, A12, • . ., A -^ can be 
run concurrently; resource allocation mechanism within separate application is not specified. 

5) MDRC-4: Radio applications have dynamic resource requirements 

This scenario assumes a similar resource manager in MD as for MDRC-3, but in addition the radio 
applications have now varying resource demands based on their current type of activity. Applications have 
separate operational states for different types of activity, and a resource budget is assigned to each operational 
state. In this scenario, we assume that software radio components in the radio application package are provided 
in platform- specific executable code. 

Resource management for MDRC-4 can be formulated as follows. Multiple applications {Aj, A2, . . ., A^} can 
be run and each application A- is divided into tasks {^yCA-), ^2(^/)' •••' ^y^(^/)}- Resource allocation is provided 
by the resource manager in MD for each task ^y(A •) -^ R(^(A-)). 

The rule for task running is exactly the same as for MDRC-3 except that each application should be replaced 
by corresponding task. Therefore, if for /7, /2, ..., iM g{ 1, ..., N},M<N, R(^y(A -y)) u R(^2(A/2)) ^ ••• ^ 
R(^^(A-^)) d R then tasks tjj(Aij), t-2{A^2), ..., hii^iu) can be run concurrently; resource allocation mechanism 
within separate task is not specified. 

6) MDRC-5: Radio applications use pre-defined static resources, on-device compilation of Software Radio 
Components 

This class corresponds to MDRC-2 with the difference that all or part of the software radio components are 
provided in the radio application package as platform-independent source code or platform-independent 
Intermediate Representation (IR), which is compiled on the MD itself. It particularly means that MD should 
include a proper compiler in order to convert the source code or IR of the software radio components into an 
executable code that runs on a given modem chip of MD. It is assumed that the methods of radio programming 
and the tools to support this category have become sufficiently standardized so that third-party vendors may 
create radio applications and activate them to different platforms with relative ease. Formal description for 
resource management is the same as for MDRC-2. 
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7) MDRC-6: Radio applications have static resource requirements, on-device compilation of Software Radio 
Components 

This class corresponds to MDRC-3 with the difference that all or part of the software radio components are 
provided in the radio application package as platform-independent source code or platform-independent IR, 
which is compiled on the MD itself. As in the case of MDRC-5, it particularly means that MD should include a 
proper compiler in order to convert the source code or IR of the software radio components into an executable 
code that runs on a given modem chip of MD. As in the case of MDRC-5, it is assumed that the methods of 
radio programming and the tools to support this category have become sufficiently standardized so that third- 
party vendors may create radio applications and activate them to different platforms with relative ease. Formal 
description for resource management is the same as for MDRC-3. 

8) MDRC-7: Radio applications have dynamic resource requirements, on-device compilation of Software Radio 
Components 

This class corresponds to MDRC-4 with the difference that all or part of the software radio components are 
provided in the radio application package as platform-independent source code or platform-independent IR, 
which is compiled on the MD itself. As in the case of MDRC-5 or MDRC-6, it particularly means that MD 
should include a proper compiler in order to convert the source code or IR of the software radio components 
into an executable code that runs on a given modem chip of MD. As in the case of MDRC-5 or MDRC-6, it is 
assumed that the methods of radio programming and the tools to support this category have become 
sufficiently standardized so that third-party vendors may create radio applications and activate them to 
different platforms with relative ease. Formal description for resource management is the same as for 
MDRC-4. 

The definition of MDRCs described above can be summarized as shown in table 5.1.1.1. 

Table 5.1 .1 .1 : Summary of MDRCs 



1 


Multi-radio 
system 


Resource 

Share 

(among radio 

applications) 


Resource 
Manager 


Multi- 
tasking 


Resource 
Measurement 


Resource 
Allocation 


MDRC-0 


No 


no 


no 


no 


Design-time 


Design-time 


MDRC-1 


Yes 


no 


no 


no 


Design-time 


Design-time 


MDRC-2 
MDRC-5 


Yes 


No 

(note1) 


Yes 
(note 2) 


Yes 
(note 3) 


Design-time 


Design-time 


Design-time 
/Install-time 


Design-time 
/Install-time 


MDRC-3 
MDRC-6 


Yes 


yes 


yes 


yes 


Design-time 


Run-time 


Design-time 
/Install-time 


^/l^D^' a 




yes 


yes 


yes 


Design-time 


Run-time 


MUHO-4 Y 
MDRC-7 ^^ 

1 


Design-time 
/Install-time 


N0TE1 : Resource share can exist among Radio Access Technologies (RATs) in a given radio application. 
N0TE2: This is for a fixed resource allocation only. Resource management and resource allocation among 

RATs (in a single RA) are pre-determined in a static manner by radio application provider. 
NOTES: Multi-tasking in this case is for multiple RATs within a single radio application. 



Note that radio conformance tests are mandatory for MDRC-1 to MDRC-7 in order to ensure that the joint operation of 
(dynamically) reconfigured base-bands and RF front-ends are in compliance with the relevant conformance 
requirements before the device is introduced to the market. 
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6 Functional Requirements 

6.1 Requirements on RAT Link Support and Management 

6.1 .1 R-FUNC-RAT-01 Function for MDRC-1 to MDRC-7 

A MD may offer support for multiple links to heterogeneous RATs being maintained simultaneously. 

6.1 .2 R-FUNC-RAT-02 Function for IVIDRC-I to IVJDRC-? 

In case that a MD offers support for multiple links to heterogeneous RATs being maintained simultaneously (in 
alignment to R-FUNC-RAT-01), in-device coexistence functionalities should be implemented. 

6.1 .3 R-FUNC-RAT-03 Function for IVIDRC-I to MDRC-7 

In case that a MD offers support for multiple links to heterogeneous RATs being maintained simultaneously (in 
alignment to R-FUNC-RAT-01), "seamless" handover of Internet Protocol (IP) data from one RAT to another RAT 
should be implemented. 

6.1 .4 R-FUNC-RAT-04 Function for MDRC-1 to MDRC-7 

In case that a MD offers support for multiple links to heterogeneous RATs being maintained simultaneously (in 
alignment to R-FUNC-RAT-01), link selection should exploit available policies, including operator/manufacturer/user 
preferences. 

6.1 .5 R-FUNC-RAT-05 Function for MDRC-1 to MDRC-7 

In case that a MD offers support for multiple links to heterogeneous RATs being maintained simultaneously (in 
alignment to R-FUNC-RAT-01), various independent IP-based connections may be maintained simultaneously. 

6.1 .6 R-FUNC-RAT-06 Function for MDRC-1 to MDRC-7 

In case that a MD offers support for multiple links to heterogeneous RATs being maintained simultaneously (in 
alignment to R-FUNC-RAT-01), one or various independent IP-based connections may be maintained simultaneously 
applying multi-homing over a heterogeneous set of RATs. Furthermore, segmentation of IP packets (sub-IP-packet load 
balancing) may be implemented. 

6.1 .7 R-FUNC-RAT-07 Function for MDRC-1 to MDRC-7 

In case that a MD offers support for multiple links to heterogeneous RATs being maintained simultaneously (in 
alignment to R-FUNC-RAT-01), (network) coding across multiple RATs may be implemented. 

6.2 Base Band Interface Requirements 

6.2.1 R-FUNC-BBI-01 Composition for MDRC-1 to MDRC-7 

Base Band Interface (BBI) shall support Radio Application Interface (RAI) for baseband signal processing (including 
real-time Media Access Control (MAC) data processing). 

Explanation: Note that MDRC-1 is included in this categorization because of only one possible case that entire 
radio application is implemented with a single function block. 
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6.2.2 R-FUNC-BBI-02 Data for MDRC-1 to MDRC-7 

BBI shall support the function of transferring receive (Rx) data from baseband processor to networking stack, the 
function of transferring transmit (Tx) data from networking stack to baseband processor. 

6.2.3 R-FUNC-BBI-03 Context Information for MDRC-1 to MDRC-7 

BBI shall support the function of transferring context information to monitor. 

6.2.4 R-FUNC-BBI-04 Interface Type for MDRC-2 to MDRC-7 

Each BBI shall support both synchronous and asynchronous interface. 

Explanation: A called function block suspends the current execution until the called block execution is 
completed in case of synchronous interfaces and vise versa for asynchronous interfaces. 

6.2.5 R-FUNC-BBI-05 Pipelining for MDRC-2 to MDRC-7 

BBI shall be applicable to fixed pipeline, programmable pipeline, and hybrid pipeline. 

Explanation: Pipeline of function blocks is determined by the contents of metadata included in the radio 

application package. Modem chip manufacturer selects one of the 3 pipeline structures for their 
baseband processor. When the baseband processor is configured according to the contents of 
metadata, the configuration of baseband processor is performed according to the pipeline structure 
adopted in a given modem chip. 

6.2.6 R-FUNC-BBI-06 Transferring of Context Information for MDRC-1 to 
MDRC-7 

BBI shall transfer context information from corresponding function block(s) in baseband processor to monitor by way 
of Baseband Parameter Aggregation (BPA) unit. 

Explanation: BPA is to minimize the extra bandwidth required for transferring context information. 

6.2.7 R-FUNC-BBI-07 Support for Multi-antenna Technologies for MDRC- 
1 to MDRC-7 

BBI shall support various multi-antenna technologies. 

Explanation: The various multi-antenna technologies include Single User-Multi-Input Multi-Output (SU-MIMO), Multi 
User-MIMO (MU-MIMO), Beamforming, Direction of Arrival (DoA) estimation, etc. 

6.2.8 R-FUNC-BBI-08 Access to Device-internal Radio Context 
Information for MDRC-1 to MDRC-7 

BBI shall provide monitor an access to device-internal radio context information via Context Information Interface 
(CII). 

Explanation: Typically, access to one or several of the below-mentioned metrics are provided: 

• Signal to Interference-plus-Noise Ratio (SINR), 

• Received Signal Strength Indication (RSSI), 

• Packet Error Rate (PER), 

• Bit Error Rate (BER), 

• Power consumption of selected Base-Band modules. 
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• MIMO algorithm configuration indicator, 

This parameter is for MD to acknowledge network a MIMO algorithm to be used at MD. 

• Precoding Matrix Indicator (PMI), 

This parameter is for MD to acknowledge network information of precoding matrix using a codebook. 

• Rank Indicator (RI), 

This parameter is for MD adopting multiple antennas to request network an approval of activating a 
desired number of antennas at MD. 

• Data rate indicator, 

This parameter is for MD to acknowledge network a maximum data rate available at a given channel 
environment. 

• Channel Coefficients Information, 

This parameter is for MD to acknowledge network information of channel coefficients. 

6.3 Base Band Function Block requirements 

6.3.1 R-FUNC-FB-01 Implementation for MDRC-2 to MDRC-7 

Each BBI shall be implemented with a corresponding function block which provides implementation code for each of 
the function block properties. 

Explanation: For example, a BBI corresponding to the function block shown in figure 6.3.1.1 is represented as 
''Name( Input, Output, Property 1, Property 2, ..., Property N^ and it is implemented with the 
corresponding function block which provides implementation code for each of the properties. 



Input 



°-h 



Name 



C 



Property 1{ } 
Property2{ } 



PropertyN{ } 



K^^ Output 

r 



Figure 6.3.1.1: Function biock defined as a baseband signal processing component 

6.3.2 R-FUNC-FB-02 Function Block for MDRC-2 to MDRC-7 

Each function block shall be defined as functionality required for implementing a radio application, including baseband 
signal processing, MAC data processing, etc. 

Explanation: Functionalities of each function block include Fast Fourier Transform (EFT), Forward Error Correction 
(EEC), MIMO encoding, MIMO decoding, Beamforming, etc. 

Figure 6.3.1.1 illustrates a function block defined as a baseband signal processing (including MAC data processing) 
component. Each function block has its name. Input, Output, and property code as shown in figure 6.3.1.1. 

6.3.3 R-FUNC-FB-03 Normative Library for MDRC-2 to MDRC-7 

The normative library shall consist of function block(s). 
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6.3.4 R-FUNC-FB-04 Execution for MDRC-2 to MDRC-7 

Each function block shall be executed only by calling corresponding BBI. 

6.3.5 R-FUNC-FB-05 Side Effects for l\/IDRC-2 to MDRC-7 

Internal state of each function block shall not be shared with any other function blocks. 

6.3.6 R-FUNC-FB-06 Shared Data for l\/IDRC-2 to MDRC-7 

A few function blocks shall be capable to share the same input data. 

6.3.7 R-FUNC-FB-07 Concurrency for MDRC-2 to MDRC-7 

A few function blocks shall be capable to be executed in parallel. 

6.3.8 R-FUNC-FB-08 User Defined Function Blocl< for MDRC-2 to MDRC- 

7 

BBI shall support user defined function block for specific radio application or specific algorithm in addition to the 
function block specified in clause 6.3.2. 

Explanation: User defined function block is provided in radio application package. It can be adopted only for 
the progranmiable pipeline or hybrid pipeline structure. The user defined function block can be 
provided in a form of platform-specific executable code, platform-independent source code, or 
platform-independent IR depending upon the capability of MD. 

6.3.9 R-FUNC-FB-09 Extendability for MDRC-2 to MDRC-7 

The normative procedure for the normative library extension by adding user defined function blocks shall be 
established. 

6.4 Mobile Device Reconfiguration Requirements 

6.4.1 R-FUNC-MDR-01 Platform-specific Executable Code for MDRC-2, 
MDRC-3 or MDRC-4 

The configuration of MD compliant to MDRC-2, MDRC-3 or MDRC-4 shall be realized with radio application package 
of which the user defined function block, specified in 6.3.8, is provided in platform- specific executable code. 

Explanation: Radio application package provided with the platform- specific executable code must be prepared 
differently for each kind of target hardware platform. Figure 6.4.1.1 illustrates a block diagram of 
method of adopting platform- specific executable code for radio application package. As shown in 
the figure 6.4.1.1, each platform- specific executable code must be generated using a specific 
compiler prepared for the corresponding target hardware platform during design time. Then, MD 
configuration is performed using installer and loader in MD. 
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Figure 6.4.1.1 : Method of adopting platform-specific executable code for radio application package 

6.4.2 R-FUNC-MDR-02 Platform-independent Source Code or IR for 
MDRC-5, MDRC-6 or MDRC-7 

The configuration of MD compliant to MDRC-5, MDRC-6 or MDRC-7 shall be realized with radio application package 
of which the user defined function block, specified in clause 6.3.8, is provided in platform-independent source code or 
IR. 

Explanation for Source Code case: 

Radio application package can adopt user defined function block in a form of platform- 
independent source code with a proper encryption. Figure 6.4.2.1 illustrates a block diagram of 
method of adopting platform-independent source code for radio application package. As shown in 
figure 6.4.2.1, since radio application package is provided in platform-independent source code, 
the user defined function block code must be compiled to generate corresponding executable code 
using a compiler prepared for specific hardware platform of MD. 
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Figure 6.4.2.1 : Method of adopting platform-independent source code for radio application package 

Explanation for IR case: 

Radio application package adopting platform-independent IR is targeted to every different kind of 
modem chip. Figure 6.4.2.2 illustrates a block diagram of method of adopting platform- 
independent IR for radio application package. As shown in figure 6.4.2.2, since radio application 
package is provided in platform-independent IR, i.e. non-executable code, platform-independent 
IR must be translated into executable code using back-end compiler prepared for specific hardware 
platform of MD. 
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Figure 6.4.2.2: Method of adopting piatform-independent IR for radio application package 

6.4.3 R-FUNC-MDR-03 Radio Configuration of Platform IVIDRC-I to 
MDRC-7 

The radio configuration of MD compliant to MDRC-1 - MDRC-7 shall be realized with activation of Unified Radio 
Applications (URA) or changing parameters of activated URA. 

6.4.4 R-FUNC-MDR-04 Radio Programming Interface for MDRC-1 to 
MDRC-7 

The Radio Programming Interface (RPI) shall provide means for description of structural and behavioural information 
ofURAs. 

Explanation: The structural information defines a set of functional blocks or URA computational operators, data 
and communications among them. The behavioural information defines execution rules and 
operator interactions. 

6.4.5 R-FUNC-MDR-05 Concurrent Execution for MDRC-1 to MDRC-7 

RPI shall provide means for explicit expression of functional blocks or operators concurrent execution. 

6.4.6 R-FUNC-MDR-06 Dynamic Execution for MDRC-3, MDRC-4, 
MDRC-6 and MDRC-7 

RPI shall provide means for explicit expression of functional blocks or operators dynamic execution. 
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6.4.7 R-FUNC-MDR-07 Formal Verification for IVIDRC-I to MDRC-7 

RPI shall provide means for formal verification of URAs. 

6.4.8 R-FUNC-IVIDR-OS Independency on Memory Model for MDRC-1 to 
MDRC-7 

RPI shall support different radio platform memory models including the shared memory and the message passing 
models. 

6.4.9 R-FUNC-MDR-09 IR Format for MDRC-5 to MDRC-7 

IR shall be expressed in a format suitable for human reading or writing and automated processing. 

6.4.1 R-FUNC-MDR-1 Timing Constraints for MDRC-1 to MDRC-7 

RPI shall provide means for explicit expression of timing constraints in baseband processing. 

6.4.1 1 R-FUNC-MDR-1 1 Intermediate Representation for MDRC-5 to 
MDRC-7 

URAs should be kept in radio application packages as IR. 

6.4.12 R-FUNC-MDR-12 Unified Radio Application for MDRC-1 to MDRC-7 

URA for MD compliant to MDRC-1 - MDRC-7 should be described in terms of the unified RPI independent on 
hardware platforms. This description is a part of the radio application package. 

6.4.13 R-FUNC-MDR-1 3 Function Granularity for MDRC-1 to MDRC-7 

Functional blocks described in terms of the RPI may have different granularity. 

Explanation: The functional blocks might be for example arithmetic operations or functions like FFT or even 
whole radio applications like Wi-Fi. 

7 Conclusions 

The present document introduces the system requirements to be met by the system architecture and protocol definitions 
work related to Base Band Interfaces. 
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